Transmission Control Protocol (TCP) is commonly used for transport-level connections for communicating data over a network, such as the Internet which uses Internet Protocol (IP) with TCP to form the commonly referred to TCP/IP transport protocol. TCP communications may be interrupted or expire for any number of reasons. Particularly in the mobile environment, TCP connections and communication performance may be adversely affected by conditions such as signal fluctuations, limited range of wireless technologies, mobility and roaming between access points which may cause a change in the underlying communication technology such as switching from a GPRS wide area network (WAN) connectivity to a wireless local area network (WLAN) connectivity, limited available bandwidth, and high round-trip delays. Accordingly, end-to-end (e2e) TCP connections between mobile stations, between mobile stations and servers, and between any network nodes, whether mobile or hardwired, can be negatively impacted. The effect of negative impact upon TCP connections also may negatively affect user experience of the mobile station or network node. For example, communications may be delayed, transfer rates may be slow to provide data, disconnections may occur, and applications may encounter errors such as stalling, hanging, and exiting with errors.
To address such problems, many solutions have been suggested to provide enhancements at different levels, including link-level enhancements such as GSM mobility, network-level enhancements such as Mobile IP (see, e.g., C. Perkins, IP Mobility Support for IPv4, RFC 3220, Internet Engineering Task Force, January 2002), transport-level enhancements such as TCP Optimizations for Wireless or MSOCKETS (see, e.g., D. Maltz and P. Bhagwat, MSOCKS: An Architecture for Transport Layer Mobility, IEEE Infocom, 1998), and session-level enhancements such as Session Initiation Protocol-SIP (see, e.g., J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, SIP: Session Initiation Protocol, RFC 3261, Internet Engineering Task Force, June 2002), SLM (see, e.g., B. Landfeldt, T. Larsson, Y. Ismailov, and A. Seneviratne, SLM, A Framework for Session Layer Mobility Management, 8th IEEE Int'l Conf. on Computer Comm'ns and Networks (ICCCN), October 1999), and SIP-based mobility (see, e.g., E. Wedlund and H. Schulzrinne, Mobility Support Using SIP, ACM Workshop on Wireless Mobile Multimedia (WoWMoM) 1999). Further, infrastructure has been developed to support TCP connections, including some of the above mentioned level enhancements, such as enhancing networks with dedicated servers, proxies, and access points such as local area caches and Mobile Agents to act as proxy nodes on behalf of mobile stations.
Adding infrastructure may not be available for such situations as ad hoc communications sessions which may be purely ad hoc or may include partially ad hoc networking and partially infrastructure-supported networking, peer-to-peer TCP/IP applications, proximity networking, and unmanaged home networking. Similarly, new enhancements to support transport level communications may require new infrastructure and software upgrades in network nodes at different levels. Accordingly, another approach to addressing transport level communications problems is to provide e2e mobility enhancements to support the connection to prevent disconnections at the TCP socket level such as MobileSocket (see, e.g., T. Okoshi, M. Mochizuki, Y. Tobe, and H. Tokuda, MobileSocket: Towards Continuous Operation for Java Applications, IEEE Int'l Conf. on Computer Comm'ns and Networks (ICCCN), 1999), ROCKS/RACKS (see, e.g., V. Zandy and B. Miller, Reliable Network Connections, ACM MOBICOM, September 2002), Mobile TCP Sockets (see, e.g., X. Qu, J. Xu Yu, and R. Brent, A Mobile TCP Socket, Int'l Conf. on Software Engineering (SE), November 1997), and Migrate (see, e.g., A. Snoeren, A Session-Based Architecture for Internet Mobility, Ph.D. Thesis, MIT, February 2003). As used herein, these types of end-to-end (e2e) services are referred to as end-to-end session enchancing (e2e-SE) services. Further, the use of these types of service frameworks may be referred to as middleware. Middleware typically refers to the software, applications, routines, and the like which operate at a middleware level to function between application layers and system or operating system layers to assist communications between application layers of different end nodes, whether performed entirely by or at the end node or, possibly, by a proxy acting with an end node. The use of middleware is intended to improve communications ultimately transmitted to and from the application layer, but designed to function as an intermediary between the application layer and communications across a network to address inconsistencies and problems resulting from direct communications between applications layers across a network. Middleware interposes between the applications and the native system networking support. Some middleware is visible to applications, possibly requiring applications to be re-compiled to use new libraries. Other middleware is transparent or invisible to the applications and provide services to support the application layer without needing to re-compile or re-link the application. For example, the Transparent, Extensible Session-Layer Architecture (TESLA) for End-to-End Network Services is a middleware framework which generalizes end-to-end transparent network services (see, e.g., J. Salz, A. Snoeren, and H. Balakrishnan, TESLA: A Transparent, Extensible Session-Layer Architecture for End-to-end Network Services, 4th USENIX Symposium on Internet Technologies and Systems (USITS), March 2003) such as the described e2e-SE services.
Middleware provides applications with a virtual socket interface though which the application can communicate. Using a virtual socket allows the actual network sockets to be destroyed and replaced as may occur and as may be necessary such as to deal with IP address changes, disconnections, and TCP expirations. A virtual socket isolates the applications from what is happening at the networking layer. Thus, instead of an application opening an actual (real) networking socket, the application opens a socket to the middleware which is a virtual networking socket between the application and the middleware layers, and the middleware opens an actual networking socket with the network (system) layer where the middleware may create and destroy actual network connections without affecting the application, therefore isolating the application layer from the network layer. A virtual socket may even be transparent to the application, the application believing that it is using an actual socket as opposed to a virtual socket. In some approaches, the application may be aware of the virtual socket and that the middleware is controlling the communications for the application. Middleware permits the end node to monitor and support the actual communication connection for disconnections and other infirmities and protect the applications of the application layer from the problems related to the communication connection such as problems related to TCP connections in the mobile environment. Of particular note about middleware is that using middleware does not require any support from infrastructure or intermediate nodes. Rather, middleware resides in each of the end nodes to allow the end nodes to collaborate regarding the manner in which the middleware will function to support network communications for the applications. Essentially, the intelligence for supporting the communication is moved from infrastructure into the end nodes. Thus, middleware is a suitable solution for transport level connections including ad hoc scenarios and scenarios without infrastructure support.
In addition to typical e2e-SE services such as support for mobility and against disconnections, other e2e-SE services which further enhance communication sessions may be offered for middleware frameworks, including e2e compression and e2e encryption services. For example, e2e compression may increase download completions, possibly transparent to the application layer. Similarly, although the application may not require encryption, the middleware communicating for the application may use e2e-SE services which provide encryption for the communications, transparent or otherwise to the application. Additional other e2e-SE services may become available for middleware frameworks to support transport level communications.
Currently, e2e-SE services are provided on a static basis, where middleware establishes communications based upon known, fixed e2e-SE services. Accordingly, to function properly, the communicating middleware of each end node has to know which e2e-SE services will be used, otherwise the nodes cannot communicate using the e2e-SE services. And each time a connection is created, such as after a TCP expiration, the middleware of the end nodes establishes the connection using the same e2e-SE services. Further, situations may change or develop between end nodes communicating using middleware which mandates or would benefit from changing the e2e-SE services operating at the middleware layer on each end node. For example, when a mobile station roams from its home network into another network, the mobile station may want to enable e2e encryption. Using current static e2e-SE services for middleware prevents e2e-SE services from changing once the session has been established.
Accordingly, there is a need in the art for an improved framework for end-to-end (e2e) session-enhancing services for transport-level connections such as to deal with constraints such as those described above including use of a static set of e2e session-enhancing services.